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ST-5 Overview 




Not much bigger than a large 
birthday cake or a small TV. 


Space Technology 5 

Tomorrow’s Technology Today 


ST-5 is a three satellite (micro-sat) 
constellation 

NASA New Millennium Program 
technology validation mission 

Help scientists understand the 
Earth's magnetosphere and its effect 
on space weather 

Uses the GMSEC architecture to 
enable cost-effective model-based 
operations to run the ST-5 
constellations lights-out 

Launched March 22, 2006 
r Three month base mission 
f Possible mission extension 






Vision to Enable Sensor Webs with "Hot Spots' 

Sensor Web Experiments, Event-driven Observations , Onboard Autonomy 


Software-driven 
Antenna Sensitivity 
Patterns - Software 
Tunes Reception to 
Targeted Satellite 


Plug-and-Play 
Flight Software 
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at we need to make this happen 



Transition from centralized mission control to distributed control 
Self-managing software components (autonomic computing) 

(1 ) Components have self-awareness 

(2) Self-optimizes 

(3) Self-healing 

(4) Self-protection 

(4) Negotiates (peer-to-peer) for resources 

(5) Functions in a heterogeneous world and with open standards 

(6) Anticipates needed resources and hides details needed to obtain 
resources 

ST-5 mission will demonstrate parts of (1), (2), (4), (5) and (6) 

• Lights-out operations with model-based software 

• Predict problems before they happen and fix early 

• Models update themselves automatically 

• Modeling system is built on top of “plug and play” architecture to 
enable easy extensibility 

• Act as stepping stone for this type of capability for future missions 

• Possibly extend capabilities during the extended mission phase 
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S Historical Background for for Model-Based 



Operations at GSFC 


■■■■■■■■■■■■I 

1987 ESP - time varying limits for GRO; Shendock, Mane 
Carlton 

■ Attempted to more closely monitor telemetry alerts over orbit’s worth 
of data and identify failure trends 

Mid- 1990’s Altair- Model-based operations approach for 
MAP and IMAGE; Coyle, Shendock 

■ State model to monitor health and safety of MAP and IMAGE, too 
expensive to maintain 

2004-2006 - Self updating model-based operations on ST-5 
constellation; Shendock, Witt, Stanley, Mandl et. Al. 

■ Cost effective model to monitor health and safety since model can 
update self via telemetry and use GMSEC message bus to initiate 
correction actions 





►T-5 Model-Based Operations Overview 
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Model Based Operations 



Command & 
Control 
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•Anomaly Prediction 

j\^ # Event Detection 

x/ •Schedule conflict 
detection 





nderlying “Plug and Play” Message Bus 
Architecture-- Goddard Mission Services 
Evolution Center ( GMSEC) 


GMSEC architecture provides a 
scalable and extensible ground 
and flight system approach 

• Standardized messages 
formats 

• Plug-and-play components 

• Publish/Subscribe protocol 

• Platform transparency 

More info at: http://amsec.asfc.nasa.aov 




GMSEC Component Catalog. 


GMSEC approach gives users choices for the components in their system. The 
TRMM mission has selected key components from the GMSEC catalog. 


► Front End Processors ► Scripting 
+ Simulators Control 


► Telemetry ♦ 
Command Systems 
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► GMSEC APIs/Ops Systems 




Python ) 


Linux 

Windows 

Solaris 


COTS Middleware: SCL, Tibco Rendezvous, Tibco SmartSockets, Eivin 



' Archiving 

^ great ) 

MTASS 


RPTS 



CAutoFC 

STK 

MTASS 

MSASS 
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► Archive + Assessment 


AutoProductS' 

► Flight 
Dynamics 


► Planning «■ 
Scheduling 
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ROME Framework 


Real-time Object Modeling Executive 
Support multiple models and multiple spacecraft 
Leverage common engineering modeling environments 
Models from various sources are easily integrated 
Fully supports GMSEC bus 
Models initialized and maintained from telemetry 
Model control via configuration file or bus directive 
Results available to GMSEC subscribers 
Easily configured via XML (Model 

Highly scalable 
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GMSEC Bus 



ST5 Specific Configuration 



ROME based implementation 
Dynamic characterization of sub-systems phenomenology 
Used by mission to manage constrained resources 
Models of Subsystems 

• Solid State Recorder (Contractor Dev.) 

• RF (Student Dev.) 

• Power (Project Dev.) 







SimulinkST5 GMSEC Highlights 



Standardized messaging interoperability 
GMSEC Compliance 

• Directives 

• AMPS 

• ASIST 

• Mnemonic Value Messages 

• ASIST 

• ITOS capability 

• Heartbeat messages 

• Log messages 

• Product Messages 
Predictive Model-Based Operations 

• Subsystem models to anticipate platform conditions in a constellation 
environment. 

• Support Short and Long Term Mission Planning 

• Interact with AMPS and ASIST for control directives, telemetry, and 
profile events. 

Constellation Operations Support 





Advantages 



Mission Planning Support 

• Offline Profile- Entire duration of operational plan 

• Real-time Profile- 4 days from current point in time 

• Configurable via XML 
User Interface 

• SimulinkST5 console 

• Web interface 

• Configured for MOC access only 

Increases ability to move toward Autonomous Operations 

• Reduce resources needed to perform analysis 
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Power 


Matlab/ 

Simulink 


SimulinkST5 


GMSEC Bus 


AMPS 


Long Term (Plan) Validation Flow 


ASIST 









|p Sample SSR Model Display to Monitor 3 
J^Virtual Recorders Each in 3 Satellites 






SSR Model Profile Showing SC 224 
FlatSat Data with VR3 Violations 






■ Re-profile command was 
issued to eliminate future VR 
violations (i.e. early saturation 
of VR capacity) 

■ New profile for VRs in 
question displayed showing 
that no VR saturations 
predicted with new profile 




SSR Model Profile After Commands 
Issued to FlatSat to Repartition SSR 






Possible Future Extensions of this 
Experiment in Extended Mission 



Transform predictive models into mobile agents that can run on 
the ground or spacecraft 

• Can be easily moved if desired, to another space-based or 
ground platform 

Simulate discovering needed service from another satellite and 
then requesting service 

• Move Simulink-based ROME models to Cosmic Hot 
Interstellar Plasma Spectrometer (CHIPS) environment 

• Run lights-out models from autonomy flight testbed, CHIPS 
testbed and CHIPS 

Build SensorML wrapper for ST-5 and allow ST-5 to discover 
predictive modeling service 
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Power Model 
Agent 


Models transformed into mobile agents 
• Working with SSR agent first 


Command 

Ingest 


Telemetry 

Output 


cFS Bus 


Adapter 


Adapter 


SSR Model 
Agent 


Power Model 
Agent 


Adapter built to make compatible with 
both GMSEC and Core Flight System 
(CFS) 

Demonstrate capability to move software 
running on GMSEC, moved onboard to 
run under CFS 

Beginning step to transform missions 
from central control to distributed control 
via self-managing software 


ST-5 Constellation 
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via Berkeley 
& Wallops 
Ground Stations 
(UDP) 


GMSEC Bus 


CHIPS - Cosmic Hot Interstellar Plasma Spectrometer 
ST-5 - Space Technology 5 


ASIST - Advanced Sp acecraft Integration and System Test 





